<race_conditions_guide>
<title>RACE CONDITIONS - TIME-OF-CHECK TIME-OF-USE (TOCTOU) MASTERY</title>

<critical>Race conditions lead to financial fraud, privilege escalation, and business logic bypass. Often overlooked but devastating.</critical>

<high_value_targets>
- Payment/checkout processes
- Coupon/discount redemption
- Account balance operations
- Voting/rating systems
- Limited resource allocation
- User registration (username claims)
- Password reset flows
- File upload/processing
- API rate limits
- Loyalty points/rewards
- Stock/inventory management
- Withdrawal functions
</high_value_targets>

<discovery_techniques>
<identify_race_windows>
Multi-step processes with gaps between:
1. Check phase (validation/verification)
2. Use phase (action execution)
3. Write phase (state update)

Look for:
- "Check balance then deduct"
- "Verify coupon then apply"
- "Check inventory then purchase"
- "Validate token then consume"
</identify_race_windows>

<detection_methods>
- Parallel requests with same data
- Rapid sequential requests
- Monitor for inconsistent states
- Database transaction analysis
- Response timing variations
</detection_methods>
</discovery_techniques>

<exploitation_tools>
<turbo_intruder>
Python script for Burp Suite Turbo Intruder:
```python
def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint,
                          concurrentConnections=30,
                          requestsPerConnection=100,
                          pipeline=False)

    for i in range(30):
        engine.queue(target.req, gate='race1')

    engine.openGate('race1')
```
</turbo_intruder>

<manual_methods>
- Browser developer tools (multiple tabs)
- curl with & for background: curl url & curl url &
- Python asyncio/aiohttp
- Go routines
- Node.js Promise.all()
</manual_methods>
</exploitation_tools>

<common_vulnerabilities>
<financial_races>
- Double withdrawal
- Multiple discount applications
- Balance transfer duplication
- Payment bypass
- Cashback multiplication
</financial_races>

<authentication_races>
- Multiple password resets
- Account creation with same email
- 2FA bypass
- Session generation collision
</authentication_races>

<resource_races>
- Inventory depletion bypass
- Rate limit circumvention
- File overwrite
- Token reuse
</resource_races>
</common_vulnerabilities>

<advanced_techniques>
<single_packet_attack>
HTTP/2 multiplexing for true simultaneous delivery:
- All requests in single TCP packet
- Microsecond precision
- Bypass even mutex locks
</single_packet_attack>

<last_byte_sync>
Send all but last byte, then:
1. Hold connections open
2. Send final byte simultaneously
3. Achieve nanosecond precision
</last_byte_sync>

<connection_warming>
Pre-establish connections:
1. Create connection pool
2. Prime with dummy requests
3. Send race requests on warm connections
</connection_warming>
</advanced_techniques>

<bypass_techniques>
<distributed_attacks>
- Multiple source IPs
- Different user sessions
- Varied request headers
- Geographic distribution
</distributed_attacks>

<timing_optimization>
- Measure server processing time
- Align requests with server load
- Exploit maintenance windows
- Target async operations
</timing_optimization>
</bypass_techniques>

<specific_scenarios>
<limit_bypass>
"Limited to 1 per user" → Send N parallel requests
Results: N successful purchases
</limit_bypass>

<balance_manipulation>
Transfer $100 from account with $100 balance:
- 10 parallel transfers
- Each checks balance: $100 available
- All proceed: -$900 balance
</balance_manipulation>

<vote_manipulation>
Single vote limit:
- Send multiple vote requests simultaneously
- All pass validation
- Multiple votes counted
</vote_manipulation>
</specific_scenarios>

<validation>
To confirm race condition:
1. Demonstrate parallel execution success
2. Show single request fails
3. Prove timing dependency
4. Document financial/security impact
5. Achieve consistent reproduction
</validation>

<false_positives>
NOT a race condition if:
- Idempotent operations
- Proper locking mechanisms
- Atomic database operations
- Queue-based processing
- No security impact
</false_positives>

<impact>
- Financial loss (double spending)
- Resource exhaustion
- Data corruption
- Business logic bypass
- Privilege escalation
</impact>

<pro_tips>
1. Use HTTP/2 for better synchronization
2. Automate with Turbo Intruder
3. Test payment flows extensively
4. Monitor database locks
5. Try different concurrency levels
6. Test async operations
7. Look for compensating transactions
8. Check mobile app endpoints
9. Test during high load
10. Document exact timing windows
</pro_tips>

<remember>Modern race conditions require microsecond precision. Focus on financial operations and limited resource allocation. Single-packet attacks are most reliable.</remember>
</race_conditions_guide>
